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== < 54 > Title: METHOD OF SECURING COMPUTER SYSTEMS BY MEANS OF SOFTWARE CONTAINMENT ~ 

jjgj (54) Titre • PROCEDE DE SECURISATION DES S YSTEMES INFORMATIQUES PAR CONFINEMENT LOGICIEL 

^ (57) Abstract: The invention relates to a method of securing computer systems involving the logical containment of data More 
< s P^;fical y the invention relates to a method of securing computer systems, which offers the possibility of executing codes that 

manipulate data which must be processed separately. The inventive method essentially involves the use of the following- (i) a memory 
f£ manager for managing memory allocation units which can be typically a fixed-size page or a variable-size block, and (ii) memory 
ON allocation owners and requesters which can be typically user applications of the operating system of the computer system or the 

SaESkr' SyStCm inVOlVCS ^ SCParati0n ° f thC ^ orementioned ^ the owner and the encryption of same 

^ (57) Abrege : La presente invention concerne la s^curisation des systemes informatiques par confinement logique de donees Elle 
O a plus parbcuherement pour objet la securisation des systemes informatiques offrant la possibility d'ex^cution de codes manipulant 
O des^donnees qui doivent etre traitees separ^ment. Elle fait essentiellement intervenir - un gestionnaire de m^moire g^rant des unites 
IT ^ l0C f ° n qw P««vent etre typiquement une page de taille fixe ou un bloc de taille variable, - des possesseurs et des 

O dema ndeurs d allocation memojre pouvant etre typiquement des applications de l'utilisateur du systeme d'exploitation du systeme 
> ^nfonrmtique ou le systeme d exploitation lui-meme. Elle exploite la separation desdites donnees par possesseur et leur chiffrement 
avec une cJe dediee. 
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5 PROCED E DE SECURISATION PES SYSTEMES TN FORMATTOITTCS PAtt 
CONFINEMENT LOGICIEL . 



10 La presente invention concerne la s6curisation des systemes informatiques 
par confinement logique de donnees. 

Elle a plus particulierement pour objet la securisation des systemes 
informatiques offrant la possibilite d'execution de codes manipulant des 
15 donnees qui doivent etre traitees s6parement. Cette separation est 
generalement dict6e par des besoins de securite. A titre d'exemple, les 
donnees du systeme Sexploitation qui conditionnent le bon fonctionnement 
de la plate-forme ne doivent pas pouvoir 6tre modifi6es par une application 
quelconque. De meme, dans les systemes permettant l'execution 
20 d'apptications multiples, les donnees d'une application doivent generalement 
Stre protegees des autres applications. 

Ces besoins prennent dans certains cas un caractere critique ; on peut penser 
par exemple, et de maniere non limitative, aux systemes embarqu6s multi- 
applicatifs du type cartes a puce, terminaux de paiement, assistants digitaux, 
ou telephones portatifs, surtout lorsque ces systemes embarques permettent 
le t61e-chargement d'apptications. En effet, ces applications telechargees 
peuvent provenir de sites multiples, qui offrent des garanties de confiance 
tres varices. 
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D'une facon generate, on sait que la plupart des solutions generalement 
adopt6es pour repondre a ce besoin de separation desdites donnees de 
systemes d' exploitation et d'applications repose sur l'utilisation de 
mecanismes proposes par le materiel. Typiquement, des unites (physiques) 
5 de gestion de memoire ("MMU, ou Memory Management Unit") associent 
des espaces physiques a des applications et les protegent contre des acces 
provenant d'autres applications. Cependant, cette solution, quand elle est 
disponible, n'est pas tres souple et s'associe difficilement aux systemes 
d'allocation dynamique de donnees (le nombre d'espaces physiques etant 
10 fixe), specialement dans le cas des systemes embarques disposant de peu de 
ressources et soumis a de fortes contraintes de securite. 

La presente invention a done plus particulierement pour but de palier a ces 
inconvenients. 

15 

Elle propose, a cet effet, de rendre plus flexible la securisation des donnees 
et de l'etendre au cas d'allocation dynamique de memoire. 

Elle fait essentiellement intervenir : 
20 - au moins un gestionnaire de memoire g6rant des unit6s d'allocation 
memoire qui peuvent 6tre typiquement une page de taille fixe ou un bloc 
de taille variable, 

- au moins des possesseurs et des demandeurs d'allocation memoire 
pouvant 6tre typiquement des applications de l'utilisateur du systeme 
25 d'exploitation du systeme informatique ou le systeme d' exploitation lui- 
meme. 



30 



Selon l'invention, le proced6 de s6curisation d'un systeme informatique par 
confinement logique de donn6es comprend la separation desdites donnees 
par possesseur et leur chiffrement avec une cle dediee ; ce processus de 
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separation et de chififrement s'effectue grace a un mode operatoire 
comprenant les 6tapes suivantes : 

- une allocation de memoire realisee par un gestionnaire de memoire a la 
demande d'un autre composant du systeme d'exploitation qui transmet 
audit gestionnaire de memoire l'identite du demandeur. Ce demandeur 
deviendra le possesseur de la memoire allouee. La transmission de 
l'identite du demandeur peut se faire soit par la gestion d'un contexte 
courant, soit par le passage de parametres aux fonctions du gestionnaire de 
memoire ; 

- un controle par le susdit gestionnaire de memoire de l'ensemble des unites 
d'allocation memoire, chacune etant associee a un possesseur de l'unite 
d'allocation memoire. Chaque unite d'allocation memoire ne peut avoir 
qu'un et un seul possesseur; neanmoins plusieurs unites d'allocation 
memoire peuvent avoir le meme possesseur ; 

un chififrement des donnees de chaque possesseur a l'aide d'une cle 
associee a ce possesseiu ; 

eventuellement une utilisation par le gestionnaire de m6moire d'un secret 
associe a chaque possesseur. Ce secret peut typiquement etre fourni au 
gestionnaire de memoire par le systeme d'exploitation au moment de 
l'introduction du possesseur dans le systeme ou a chaque acces a une unite 
d'allocation memoire ; 

eventuellement une utilisation par le gestionnaire de memoire d'une cle 
pour chaque possesseur. Cette cle peut par exemple 6tre ddrivee d'un 
secret associe au possesseur et une cle dite "maitre" a laquelle seul le 
gestionnaire de memoire a acces ; 

une verification par le gestionnaire de memoire, pour chaque demande 
d'acces a une unite d'allocation memoire, de l'identite du demandeur ; si 
cette identite n'est pas identique a celle du possesseur de ladite unit6 
d'allocation memoire, alors 1'acces a l'unit6 d'allocation memoire est 
reruse par le gestionnaire de memoire ; 
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- une realisation par le gestionnaire de memoire du chifrrement (dans le cas 
d'une demande d'ecriture) ou du.decmfrrement (dans le cas d'une demande 
de lecture) des donn6es concemees avec la cl6 associ6e au possesseur, 
cette cle pouvant 6tre recalculee par le gestionnaire de memoire. 

5 

Ainsi, les donnees des differents possesseurs etant chiffrees de maniere 
automatique, par un secret que seul le gestionnaire de memoire connait, il est 
impossible pour une application d'avoir acces aux donnees d'un autre 
possesseur. 



10 



Deux situations peuvent se presenter lorsqu'un tiers tente d'acceder a une 
unite d'allocation memoire qui ne lui appartient pas : 

- cette tentative peut 6tre declenchee par l'mtermediaire du gestionnaire de 
memoire : dans ce cas, le contrdle effectue par le gestionnaire de memoire 

15 conduit automatiquement au rejet de la demande ; 

- cette tentative peut 8tre d6clenchee de maniere illicite, sans passer par 
l'intermediaire du gestionnaire de memoire, par acces direct a la memoire 
physique, dans le cas ou les verifications effectuees par le materiel ne 
suffisent pas a ecarter cette possibility : le tiers pourra alors effectuer une 

20 lecture, mais, ne disposant pas de la cle de dechifrrement, il obtiendra des 
donn6es inutilisables. 



25 



A partir du moment ou la cle maitre est memorisee dans une zone prot6g6e, 
la confidentialite des donn6es est done preservee dans les deux cas. 



Avantageusement, le proc6de selon l*invention ne d6pend pas du fait que 
l'unit6 d'allocation m6moire soit une page logique de taille fixe ou un bloc de 
taille variable. Dans le cas ou runite d'allocation est la page, le procede se 
raffinera de la fa?on suivante : lorsque le gestionnaire de memoire recoit une 
30 demande d'allocation d'un bloc pour le compte d'un possesseur, il recherche 
d'abord une page ayant le mSme possesseur ; ainsi, tous les blocs allou6s par 
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un possesseur d'unite d'allocation m6moire se trouvent regroupes dans une 
ou plusieurs pages dediees. 



Le procede selon l'invention pourra etre am61iore de plusieurs manieres (non 
5 exclusives) : 

- Au lieu d'associer une cle unique a un possesseur donn6, le gestionnaire 
de memoire peut associer une cle a chaque ensemble possesseur et unite 
d'allocation memoire. Cette amelioration a deux avantages : d'une part, 
10 elle reduit les probability de decouverte des cles utilisees (en cas 
d'attaque cryptographique) puisque chaque cle sera utuisee moins 
souvent ; d' autre part, elle reduit les risques en cas de d6couverte d'une cle 
puisque seule l'unite d'allocation memoire associee sera mise en danger. 

15 - Le gestionnaire de m6moire peut 6galement integrer dans chaque unite de 
memoire une zone permettant d'en verifier l'integrite, par exemple a partir 
d'un simple "checksum" (somme des controles) signe ou d'un algorithme 
cryptographique. La donnee contenue dans cette zone est mise a jour par 
le gestionnaire de memoire a chaque acces en ecriture a l'unit6. Elle peut 

20 6tre utilisee par le gestionnaire de memoire a des fins de verification, soit 
systdmatiquement a chaque acces a l'unite, soit de fapon p6riodique. La 
verification consiste simplement, avant l'acces demande, a recalculer la 
donn6e d'integrite a partir du contenu de l'unite (donn6es en clair) et a la 
comparer a la donn6e contenue dans la zone d'integrite. Une modification 

25 intempestive ou illicite du contenu de l'unite pourra alors 6tre detect6e, ce 
qui renforcera la securite de la gestion des donnees. 
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- L' association de differents niveaux de securite aux applications et 
l'utilisation de moyens de chiffrement differents (typiquement 
algorithmes, longueurs de cl6s) selon le niveau de securit6 associe 
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permettent de proportionner le cout de mise en oeuvre (temps d'execution 
notamment) a l'objectif recherche en matiere de securit6. 

A titre d'exemple non limitatif, il pourra etre justifie de reserver les moyens 
5 cryptographiques les plus puissants (et les plus couteux) pour la protection 
d'une unit6 de memoire destinee a recevoir des clefs de chiffrement ou des 
droits d'acces. 

- La combinaison du proced6 selon 1' invention a un m^canisme de 
0 protection physique (MMU) permet une protection a granularit6 plus fine. 
Par exemple, les applications peuvent 6tre regroupees en plusieurs grandes 
cat6gories (6ventuellement, et de maniere non limitative, selon le niveau 
de confiance qu'on peut leur accorder, la premiere distinction naturelle 
pouvant etre entre applications des utilisateurs et applications du systeme 
5 Sexploitation), chaque categorie etant protegee des autres par le 
mecanisme physique et les applications 6tant protegees entre elles par le 
proc6de de confinement logiciel selon l'invention. 
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REVENDICATIONS 

1. Proc6de de securisation par confinement logiciel d'un systeme 
informatique qui execute des codes manipulant des donnees, faisant 
5 intervenir : 

- au moins un gestionnaire de memoire gerant des unites d'allocation 
m6moire qui peuvent 8tre typiquement une page de taille fixe ou un bloc 
de taille variable, 

- au moins des possesseurs et des demandeurs d'unites d'allocation 
10 memoire pouvant etre typiquement une application de l'utilisateur du 

systeme d' exploitation du systeme informatique ou le systeme 
d'exploitation lui-meme, 
caracteris6 en ce qu'il comprend les etapes suivantes : 

- une allocation de memoire realisee par le gestionnaire de memoire a la 
15 demande d'un autre composant du systeme d'exploitation qui transmet 

audit gestionnaire de memoire l'identite du demandeur ; 

un contrdle par le susdit gestionnaire de memoire de l'ensemble des 
unites d'allocation, chacune etant associee a un possesseur de l'unite 
d'allocation memoire ; 
20 - un chifrrement des donn6es de chaque possesseur a l'aide d'une cle 
associee a ce possesseur ; 

- une verification par le gestionnaire de m6moire, pour chaque demande 
d'acces a une unite d'allocation memoire, de l'identite du demandeur ; si 
cette identit6 n'est pas identique a celle du possesseur de ladite unite 

25 d'allocation memoire, alors l'acces a l'unite d'aUocation m6moire est 
refuse par le gestionnaire de m6moire ; 

- une r6alisation par le gestionnaire de memoire du chiffrement (dans le cas 
d'une demande d'ecriture) ou du decMffrement (dans le cas d'une demande 
de lecture) des donnees concemees avec la cle associee au possesseur, 

30 cette cle etant au moins recalculee par le gestionnaire de memoire. 
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2. Proced6 selon la revendication 1, caracterise en ce que l'unite 
d'allocation est la page, et que le gestionnaire de memoire, lorsqu'il recoit 
une demande d'allocation d'un bloc pour le compte d'un possesseur d'unite 
d'allocation memoire, recherche d'abord une page ayant le meme 

5 possesseur de facon a ce que tous les blocs alloues par ledit possesseur se 
trouvent regroupes dans une ou plusieurs pages d6di6es. 

3. Procede selon la revendication 1, caracterise en ce que la 
transmission de l'identite du demandeur se fait soit par la gestion d'un 

10 contexte courant, soit par le passage de parametres aux fonctions du 
gestionnaire de memoire. 

4. Procede selon la revendication 1, caracterise en ce que le 
gestionnaire de memoire calcule dynamiquement la cle d'un possesseur a 

15 partir d'un secret associ6 audit possesseur et d'une cle dite "maitre" a 
laquelle seul le gestionnaire de memoire a acces. 

5. Proced6 selon la revendication 1, caracterise en ce que le 
gestionnaire de memoire associe une cle a chaque ensemble possesseur et 

20 unit6 d'allocation memoire au lieu d'associer une cle unique a chaque 
possesseur. 

6. Procede selon la revendication 1, caracterise en ce que le 
gestionnaire de memoire integre dans chaque unite d'allocation memoire une 

25 zone permettant d' en verifier T integrite. 

7. Proc6d6 selon la revendication 1, caracterise en ce qu'il associe 
differents niveaux de securite aux applications et utilise des moyens de 
chiffrement differents selon le niveau de securite associe. 



) 

K 
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8. Precede selon la revendication 1, caracterise en ce qu'il est combine 
a un m6canisme de protection physique. 



5 



9. Precede. . selon la revendication 1, caracterise en ce qu'il est 
impl6ment6 sur un systeme embarque tel un terminal du type telephone 
portatif, un terminal de paiement bancaire, un terminal de paiement portatif, 
un assistant digital ou "PDA", une carte a puce. 



